Security in electronic transactions using smart cards is based on cryptographic techniques. The smart card chip's processor calculates and sends a digital signature for the transaction, constituting proof of the issuing party's agreement to the signature in the transaction. Said proof is specific to the issuing body that manages the application. Said digital signature is the result of a calculation based on the data identifying the card's issuer, terminal, transaction number, transaction amount and possibly the card bearer's account number.
The data is sent to the card's issuer who performs appropriate processing such as auditing the transaction by checking the signature, issuing it for payment, debiting the customer account, crediting the service supplier's account, etc.
In one of the previous methods described in FR-A-2 74 B 591, the card produces two signatures, the first of which is called the “long” signature (the public key algorithm) and is intended for the service provider, and the second of which is called the “short” signature (the private key algorithm [hereinafter referred to as “S”]) and which is encapsulated within the first and is intended for the issuer. The service provider checks the long signature and, if the result is correct, provides the service ordered and stores the short signature. At the end of the day, it sends the stored short signatures and the corresponding data to the issuer.
Although the advantage of this structure is its simplicity, it does however cause certain problems when payments are made using an electronic wallet (PME), as it is sometimes necessary to include one or more intermediate actors between the three previously-named parties (the bearer, the service provider and the issuer), depending on requirements for intermediate levels of concentration in calculating running totals of electronic values.
One solution consists in adding intermediate resources called SAMs (“Secure Application Modules”) that check one of the two signatures produced by the card and calculate the running total of electronic values received.
If intermediate SAMs could perform the same check as that carried out by the issuer, security levels would be degraded because if the cryptographic algorithm used to produce the signature for the card's issuer used a secret key the issuer's key would have lower security levels than the guarantee provided by the electronic wallet.
If the second, service provider's, signature was produced by a public key algorithm, the intermediate SAMs, like the service provider, would be able to authenticate any transaction sent from a PME. However, in this scenario the signatures would be considerably longer and so more expensive to transfer, store and check.
The aim of the present invention is to remedy precisely these drawbacks.